The default permission on WindowsProcess is now PROCESS_VM_READ (a 2.0
breaking change), so existing write tests in test_editor.py started
failing on Windows CI. Explicitly request VM_WRITE | VM_OPERATION on
Win32; Linux and macOS ignore the kwarg as before.

- Add mypy override that ignores errors in win32/linux/macos backends.
  Each backend uses symbols (ctypes.windll, WINFUNCTYPE, Mach types) that
  only resolve on their target OS; mypy running on one host can't validate
  the others.
- Cast() generic-return-vs-concrete-bytes/str in convert_from_byte_array.
- Loosen get_c_type_of return type to Any (returns either _SimpleCData or
  ctypes.Array without a common base).
- Tighten _as_bytes to only treat real bytes as a no-op (bytearray now
  goes through the bytes() conversion).
- Move GetProcessIdByWindowTitle import into the function body so mypy
  on non-Windows hosts doesn't see it as undefined.

test_search_by_int and test_search_by_float iterate every address yielded
by search_by_value_between and read it back to verify the value. A page
mapped at scan time can be decommitted/protected before the subsequent
read — the syscall now surfaces this as OSError (it used to silently
return zeros). Wrap the read in try/except OSError, matching the pattern
already used in test_search_by_string.

VirtualQueryEx requires PROCESS_QUERY_INFORMATION (or PROCESS_QUERY_
LIMITED_INFORMATION) in addition to PROCESS_VM_READ. With only
PROCESS_VM_READ — the previous default — VirtualQueryEx returns 0, so
get_memory_regions / snapshot_memory_regions / search_by_value* /
search_by_addresses all came back empty. Exposed by Windows CI when
test_region_snapshot opened a process without an explicit permission.

The new default is PROCESS_VM_READ | PROCESS_QUERY_INFORMATION (exposed
as the DEFAULT_PERMISSION constant). README and CHANGELOG updated.
tests/test_editor.py also adds PROCESS_QUERY_INFORMATION to its
permission combo to make the read-back loop in search-by-value tests
robust across Windows versions (it happened to work in Python 3.11 by
implicit grant, but the explicit bit makes it deterministic).

GitHub's macOS-latest runner pool is much smaller than ubuntu/windows.
Running 6 Python versions × macos in parallel stalls the PR for 10+
minutes in queue without acquiring a runner. macOS only validates that
the Mach backend works — the Python version doesn't change that surface,
so we drop down to a single (stable) Python on macos-latest while
keeping the full 6-version matrix on ubuntu/windows.

The macos-latest (Apple Silicon arm64) runner pool is heavily congested
on free-tier accounts — jobs sit in queue for 15+ minutes without
acquiring a runner. The macos-13 (Intel x86_64) pool is much larger
and exercises identical code paths: Mach VM structs are fixed-size by
design (mach_port_t = uint32, mach_vm_address_t = uint64, etc.), so
x86_64 and arm64 hit the same struct layout and syscall surface.

GitHub-hosted macOS runner pools are often congested and a job can sit
in queue for 30+ minutes without acquiring a runner. Stop the PR from
stalling on this:

- continue-on-error: true for macOS jobs (ubuntu and windows still gate
  the merge; macOS is best-effort)
- 25-minute timeout caps the wait; real test runs finish in well under
  10 min when a runner is available

timeout-minutes counts execution time, not queue time, so a macOS job
stuck waiting for a runner can stall a PR indefinitely. The fix:

- Split macOS into its own build-macos job
- Gate it with: if: github.event_name != 'pull_request'
- Runs on push-to-main, weekly cron, and workflow_dispatch — never blocks
  a PR

PRs are gated by ubuntu × 5 Pythons + windows × 5 Pythons + lint, which
already provides cross-platform coverage. The Mach backend is validated
by the merged code via cron/dispatch and by local self-process tests in
dev.

GitHub-hosted macOS runners are heavily congested on free-tier accounts.
Even with continue-on-error and timeouts, the job blocked the workflow
UI for tens of minutes per run. The Mach backend is covered by local
self-process tests in dev; contributors with macOS hardware can run the
suite directly.

Drop PyMemoryEditor.sample (Tk) in favour of PyMemoryEditor.app, a
PySide6/Qt app that exercises every public surface of the library:
all eight ScanTypesEnum modes, the five value types
(bool/int/float/str/bytes), search_by_value / search_by_value_between
(with progress_information, writeable_only, region snapshot reuse),
search_by_addresses, read_process_memory, write_process_memory,
get_memory_regions / snapshot_memory_regions, plus value freezing and
a live hex viewer. Wired up as the pymemoryeditor CLI and a new
[app] optional-dependencies extra for PySide6.

Also extends the .flake8 ignore list with E203 (black-compatible
slice spacing, mirroring the existing W503 ignore), and updates the
README + CONTRIBUTING accordingly.

Black-style reformatting (slice spacing, line breaks around imports,
blank line after class docstrings, etc.) across the cross-platform
backends, util/, process/, the tests, and the two app modules the
editor revisited after the previous commit. No behaviour changes; the
.flake8 already tolerates E203 / W503 for compatibility with this
style, so make lint stays green.